Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/lists/mint/l_1599/1313

Internet Message Format | 1994-08-27 | 4.9 KB

Subject: Re: Just a couple of things.
Date: Wed, 27 Apr 94 12:53:12 +0200
From: Erling Henanger <[e-mail]>

>
> >> Filesystems would layer above this model. As the Falcon SCSI and TT SCSI are
> >> mutually exclusive they could use the same virtual device numbers. Devices
> >> would be numbered in the same way as Atari does, ie. ACSI are 0-7 and SCSI
> >> are 8-15.
> >>
> >> To do this I'll need to get information on the following:-
> >>
> >> (a) SCSI commands
> >> (b) TT SCSI chip programming
> >> (c) Falcon SCSI hardware addresses and programming
> >
> >You're reinventing the wheel here. It would be much more efficient
> >in terms of developping time if we could agree on an XHDI extension
> >which allows to send ACSI/SCSI commands to the hard disk driver.
> >This way, you would only have to write the device driver interface
> >code and wouldn't have to care about low-level stuff.
>
> I think the important thing, however, is to integrate SCSI/ACSI into a
> MiNT-level driver rather than one below it so that it can fully integrate
> with MiNT so that the whole machine doesn't just hang every time you do a
> disk access, as the current ACSI/SCSI drivers tend to do.
>
> The senario I'd like to see is something like this:-
>
> A process wants to send a command to a SCSI device which may take a while to
> respond. It uses the SCSI API layer to send the command. The SCSI device
> driver sends the command, disconnects from the device, puts the process
> on an I/O wait queue and returns control to MiNT. Sometime later the device
> responds to the command, the SCSI driver notices, passes the reply into the
> address space of the process and puts the process on the run queue.
>
> A device driver below MiNT cannot do this.
>
> >The only problem here is that you need a hard disk driver that offers
> >such a service. Atari will certainly not update their hard disk driver
> >in that direction, and I don't think that ICD offers a full XHDI
> >interface. Therefore I have the following suggestion:
> >
> >A few years ago, I wrote a hard disk driver of my own, called CBHD.
> >It has been published as part of a book that I wrote ("Scheibenkleister"),
> >together with other hard disk maintenance software. At the time,
> >the book and the driver were very successful in Germany.
>
> It would be a good starting place for the driver code. It's important that
> the code is also forward looking, able to handle devices with sizes greater
> than 4GB etc. This would mean being able to support at least 64bit block
> numbers.
>
> >In the meantime, the book is out of print, and I don't have the
> >time to offer a full-blown support for the hard disk driver.
> >I know, however, that it is quite good; it's fast (I believe
> >it is the fastest of them all 8-), reliable (thousands of users
> >have tested it with quite a lot of configurations), and in the
> >meantime it has also become a little more modular so that it can
> >be extended more easily. I don't want this piece of software just
> >lie around on my hard disk. If there's enough interest, I would be willing
> >to give this hard disk driver into the public domain, under similar
> >terms as other MiNT-related software and MiNT itself so that other
> >people could hack it up and extend it. I have prepared the driver
> >for XHDI support, but only two or three XHDI functions are implemented
> >right now. It's not that tricky to add the other ones, though.
> >I just don't have the time for it. I would be willing, though,
> >to coordinate releases, i.e. collect, check and send out patches,
> >at least in the beginning until I have found out whether this
> >is manageable or not.
> >
> >So if you think a PD hard disk driver would be a good idea, please
> >say so. I need some support for it, and I won't release CBHD into
> >the public domain if I don't know that there will be some people
> >who will actually add value to it and use it.
>
> Anything would be better than AHDI, ICD and their kin! :-)

Well, at least with source code to the CBHD driver, we would be able
to make such a driver. Making the driver respond to interrupts instead
of polling can't be that big a problem. At least not when all the
scsi setup code can be ripped off this driver. How much work it will
be to setup the queues of processes wanting to do IO under MiNT
I won't comment on.
I am sure there are people on this list that can comment much better
on this.

>
> >Let me know what you think!

I like the idea !

> >
> >[e-mail]-----------------------------------------------
> >Claus Brod, MDD, HP Boeblingen         Have you hugged your manager today?
> >--#include <std_disclaimer>-----------------------------------------------
>
> Steve
>
> --
> ---------------------------------------------------------------------------
> Computer Systems Administrator, Dept. of Earth Sciences, Oxford University.
> E-Mail: [e-mail] (JANET) [e-mail] (Internet).
> Tel:- Oxford [phone] (UK) or [phone] (International).

Erling